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(57) Abstract: The present invention relates 
to a computer system with a host processing 
unit (1) executing a host operating system 
(3). This computer system has a driver code 
simulating a hardware device interface for a 
process (PRl) running in the host operating 
system (3). The computer system has also 
simulation code to process data to and 
from the driver code in accordance with the 
hardware device interface. This simulation 
code creates the process (PRl), while 
simulau'ng another operating system within 
the process (PRl). 
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Computer simulator enabling hardware simulation. 

5 This invention relates to computer technology, more 
particularly, but not exclusively, to the simulation of 
computer environments . 

A simulation may be created within a hosting computer 
10 platform. This is useful for example when new software must 
be developed for a given target machine, because the 
simulation provides a convenient interface to develop the new 
software, i.e. an Operating System (or portions thereof) 
and/or a new application software. 

15 

However, as it will be described later in more detail, 
simulation of hardware is not available in such a simulation 
system. This is a problem in certain situations, e.g. where 
networking functions are desired. 

20 

More generally, a problem may occur when a process is running 
within a multi-process operating system, and when that 
process intends to directly access hardware resources which 
are under control of the host multi-process operating system. 
25 This also will be described later in more detail. 

This invention aims at improving the situation. 

In accordance with one aspect of this invention, provision is 
30 made for a computer system comprising: 

- a host processing unit capable of executing a host 
operating system, 

- driver code capable of simulating a hardware device 
interface for a process running in said host operating 

35 system, and 

- further code capable of processing data to and from the 
driver code in accordance with the hardware device interface 
being simulated. 
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The computer may further comprise simulation code, capable of 
creating a process running in said host operating system, 
while at least partially simulating another operating system 
within the process being created. In other words, another 
5 operating system is simulated within the host operating 
system, as it will be seen in more detail hereinafter. Thus, 
the driver code may provide the simulated operating system 
with a simulated hardware device interface. 

10 The invention may also be defined as a method of executing 
software in a computer, comprising the steps of: 

a) providing a host processing unit having a host operating 
system, 

b) providing driver code capable of simulating a hardware 
15 device interface for a process running in said host operating 

system, and 

c) providing further code capable of processing data to and 
from the driver code in accordance with the hardware device 
interface being simulated. 

20 

Another method may alternatively be defined as: 

a) running a process in a host processing unit having a host 
operating system, 

b) simulating a hardware device interface for said process, 
25 and 

c) providing said host operating system with further code 
capable of exchanging data with said process in accordance 
with the hardware device interface being simulated. 

30 In an embodiment, step a) may be capable of at least 
partially simulating another operating system, and step b) 
provides the simulated operating system with a simulated 
hardware device interface. In addition, step b) may comprise 
at least partially simulating a communication interface. 

35 Thus, the further code (214) of step c) may enable the 
exchange of data between a first process and a second process 
running in said host operating system. 
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Still in addition, the further code of step c) may also be 
capable of exchanging data between the simulated hardware 
device interface and a physical hardware device interface. 

5 The invention may be further defined as a method of 
simulating a computer architecture having a device 
communication interface, comprising the steps of: 
a) in a host operating system, simulating another operating 
system, 

10 c) simulating a hardware device interface for said another 
operating system, and 

d) supplementing said host operating system with further code 
capable of processing data to and from said hardware device 
interface being simulated. 

15 

In a non-limiting embodiment, the further code is capable of 
exchanging data between a first execution of the driver code 
for a first operating system emulating process and a second 
execution of the driver code for a second operating system 
20 emulating process. The first and second operating system 
emulating processes may be installed on the same computer, or 
on different computers. 

The invention also extends to the software comprising the 
25 driver code and/or the further code adapted to work in 
accordance with the invention. 

Other alternative features and advantages of the invention 
will appear in the detailed description below and in the 
30 appended drawings, in which : 

- figure 1 is a general diagram of a computer system in which 
the invention is applicable; 

35 - figure 2 diagrammatically shows the organization of the 
computer system of figure 1, hosting two operating system 
emulating processes; 
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- figure 3 diagranunatically shows the software architecture 
of the computer system, in connection with the operating 
system emulating processes of figure 2; 

5 - figure 4 diagranunatically shows, the network architecture of 
the computer system of figure 3; 

- figure 5 shows the general structure of an Internet 
transmission system having an IP stack; 

10 

- figure 6 is a flow chart describing the method of 
simulating the environment according to the invention. 

- figure 7 is a flow-chart functionally describing the 
15 operation of a system according to this invention. 

Making reference to software entities imposes certain 
conventions in notation. For example, in the detailed 
description, the quote sign " may be used as character string 
20 delimiter when deemed necessary for clarity (e.g. "rsh"). 

Real time embedded operating systems are of increasing 
interest in various applications. An example is the operating 
system named ChorusOS (a product and trademark of SUN 
25 MICROSYSTEMS). Some existing versions of ChorusOS are defined 
in "Sun Embedded Workshop, ChorusOS Technical Overview", 
CS/TR-96-119, SUN MICROELECTRONICS, Palo Alto, California 
94303, USA. In ChorusOS, the processes are termed "actors". 

30 In order to be installed on a particular machine ("target"), 
an operating system like ChorusOS should be prepared in 
accordance with the target characteristics, including the 
target's main board, a corresponding board support package 
(BSP), and the target's specific drivers. Usually, the target 

35 will include additional devices, also with their own drivers. 

Usually, the target is not a conventional machine, e.g. 
usually each target is different. This means that a software 
engineer often has no target machine available, at the time 
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he wants to develop application software to be run within the 
target architecture (target machine and target operating 
system). Moreover, in some cases, the target hardware is 
under development concurrently with the corresponding 
5 software, i.e. the exact physical target architecture does 
not exist yet. 

Although the above problem has been noted in the context of 
a real time embedded operating system, an example of which is 
10 ChorusOS, the same problem may also exist more generally with 
any type of target operating system. 

One possible solution to the problem is to use a simulation 
system, i.e. a computer system simulating the target machine. 
15 The simulation system may be based on a hosting computer 
platform ("host"), having its own operating system (host 
operating system] . The hardware of such a host is for example 
as shown in Fig. 1, where: 

- 11 is a processor, e.g. an Ultra-Sparc (SPARC is a 
20 Trademark of SPARC International Inc); 

- 12 is a progreun memory, e.g. an EPROM for BIOS; 

- 13 is a working memory, e.g. a RAM of any suitable 
technology (SDRAM for example); 

- 14 is a mass memory, e.g. one or more hard disks; 
25 - 15 is a display, e.g. a monitor; 

- 16 is a user input device, e.g. a keyboard and/or mouse; 
and 

21 is a network interface device connected to a 
communication medium 20, itself in communication with other 
30 computers, which may include further simulation systems in 
accordance with this invention. Network interface device 21 
may be an Ethernet device, a serial line device, or an ATM 
device, inter alia. Medium 20 may be based on wire cables, 
fiber optics, or radio-communications, for example. 

35 

Data may be exchanged between the components of Figure 1 
through a bus system 10, schematically shown as a single bus 
for simplification of the drawing. As is known, bus systems 
may often include a processor bus, e.g. of the PCI type, 
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connected via appropriate bridges to e.g. an ISA bus and/or 
an SCSI bus. 

In figure 2, the CPU and hardware of figure 1 is 
5 diagraininatically shown as 1. The host also has an operating 
system 3, e.g. Solaris (an operating system product and 
trademark of SUN MICROSYSTEMS). It will be appreciated that 
such an host may be used for a variety or applications, and 
is therefore a widespread type of computer platform. 
10 Additionally, operating systems other than Solaris may be 
used in accordance with the invention. 

When host operating system 3 has been loaded in the host, 
several independent processes may be run therein. The host 
15 may for example be a Solaris-Unix platform, capable of 
running Unix applications, using Unix processes (Unix-Solaris 
daemons). This may include the following Unix functions: 

- "rsh" (RemoteSHell) , for executing a command in a remote 
station, defined by its IP address, 

20 - "ping", for testing whether a remote machine is alive, 

- "nfsd" (NFS Daemon), for implementing a Network File 
System, 

- "rarpd" (Reverse Arpanet Resolution Protocol Daemon), which 
provides an IP address corresponding to an Ethernet address. 

25 

When simulating a target, the host has a set of software 41 
- comprising a process PRIA, and a simulation program SMIA. A 
target application software TAIA runs in simulation program 
SMIA. Similarly, at 42, an application TAlB runs in a 

30 simulator SMIB, which is part of a process PRIB in host 
machine HMl. The number of simulator processes depends upon 
the available RAM, and upon the amount of memory per process, 
inter alia. A typical amount is 32 Megabytes per process, 
which may be allocated both from RAM 13 and from virtual 

35 memory created on hard disk 14, allowing e.g. up to 254 
simulators to run in the same host. However, these numbers 
are merely exemplary, as any number of configurations are 
within the scope of the present invention. 
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In the following description, unless otherwise indicated, or 
suggested by the context, the designations like PRIA, PRIB or 
PR2A may be used to encompass the process together with the 
simulation program and the possible target application( s) . 

5 

It will be appreciated that the simulation progreims 41 and/or 
42 act as a simulated interface, i.e. provide target software 
TAIA and/or TAIB (Figure 2) with a target interface within 
the simulation host. In fact, the expression "target 
10 software" may cover: 

- the target operating system (e.g. ChorusOS), which may be 
developed, or, at least adapted and tested, using the 
simulation system; 

- target application software; when the target operating 
15 system is finalized (if required), the simulator program, now 

including the target operating system, forms a target 
architecture interface, for use in the development of target 
application software; 

- optionally, a programming environment, enabling in situ 
20 development and debugging of the application software to be 

run in the target. 

An example will now be described to show simulation of 
ChorusOS in more detail on a Solaris/Sparc host computer 
25 system. The example is intended only to illustrate a context 
in which the invention may apply, without any restrictive 
purpose. However, the invention should not be limited to 
ChorusOS and Unix. Other systems and operating systems are 
equally applicable. 

30 

The simulation is intended to simulate a ChorusOS operating 
system embedded in a physical target. In particular, the 
simulation supports Ethernet functionality allowing: 
. simulator accessibility from a Solaris host, via e.g. Unix 
35 calls "rsh" or "ping", 

. access from the simulator to Solaris host's resources via 
standard Unix-Solaris daemons, e.g. "nfsd" or "rarpd". 
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A ChorusOS simulator may be designed as a UNIX executable 
file, which may be run on top of a native UNIX operating 
system in a Solaris/Sparc computer system. The UNIX 
executable file may be viewed as a port of ChorusOS on the 
virtual machine provided by a Solaris process. Then: 

- portable layers are identical to those of ChorusOS on a 
physical machine; 

- platform dependent layers of ChorusOS make use of Solaris 
system calls; and 

- the simulator can use Solaris libraries in order to: 
. manage memory, interruption, and process contexts; and 
. access stream functionalities of Solaris, as it will 
be seen hereinafter. 

Initiation of the simulator will now be described. Initiation 
involves a specific utility, a "loader", in charge of: 

- allocating e.g. 32 Megabytes of virtual memory, 

- copying the basic ChorusOS file (so called "archive") into 
memory ; 

- activating the archive entry point, thereby launching the 
simulator. 

The above defined example will be referred to as needed. It 
involves no limitation of any kind. In particular, the 
25 invention is not restricted: 

- to Solaris/Sparc as a host architecture; 

- to Unix processes as simulator processes; 

- to ChorusOS as a target operating system being simulated. 

30 When simulating an operating system, and in other contexts of 
computer technology, the simulated process (or processes) 
expects to have direct control on certain hardware devices . 

However, hardware resources are generally under exclusive 
35 control of the host operating system. This means that the 
simulation system cannot simulate hardware resources, e.g. a 
processor, a keyboard or a display, within the virtual target 
interface it offers to the target operating system. 
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This is a problem, since simulating hardware may be useful 
for various purposes (for example, simulating a processor). 
More specifically, it is often desirable to simulate 
communication hardware, e.g. an Ethernet connection, as it 
5 will be described now, or an ATM connection. 



In the above defined example, the simulation system provides 
a ChorusOS target implementing ChorusOS functionalities, 
within a Unix process in a Solaris/Sparc machine. In fact, 

10 target application software will run natively on the Solaris 
machine within a ChorusOS environment. As indicated, the 
simulation system provides interface simulation, i.e. it 
provides target application software with a ChorusOS 
interface within the Solaris machine. This is called a 

15 "virtual target". 

Now, in this example, ChorusOS may contain an IP network 
protocol stack (The IP stack is often termed TCP/IP stack, 
although, instead of TCP, it may use UDP as well). The bottom 
20 layer of the IP stack is arranged to exchange packets through 
hardware communication devices such as an Ethernet device, a 
serial line device, or an ATM device, inter alia. 

The case of an Ethernet network will now be considered by way 
25 of example. In this case, the Ethernet bottom layer of the IP 
stack expects to exchange packets having Ethernet 
encapsulation with an Ethernet device. 

However, the host operating system (Solaris in this example) 
30 exerts full control on the communication devices existing in 
the host. For example, when receiving an IP packet from e.g. 
an Ethernet device, the host operating system firstly removes 
the Ethernet header from the packet (de-encapsulation), and 
then it analyses the de-encapsulated packet's IP header. 
35 Then, the host operating system either accepts that packet or 
forward it onto another network device, depending upon 
whether the IP address in the packet's IP header corresponds 
to a local IP address, or not. 
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Since the simulation system is a local process (a Unix 
process in this example), it may receive only such a de- 
encapsulated packet, i.e. cannot "see" the encapsulated 
packet as it would come from a hardware communication device. 

5 

In order to resolve this problem, one might think about 
altering the host operating system to remove its exclusive 
control on hardware resources. Although theoretically 
possible, this solution is considered practically 
10 inefficient. This solution would require that a special 
version of the host operating system be built, which raises 
many difficulties, and, additionally would result in losing 
the versatility of the host computer platform. 

15 In short, it is not possible for a process to share a 
communication device with the host operating system. As a 
consequence, a target simulation cannot directly access the 
communication devices of the host. 

20 On another hand, using a simulator system with restricted 
capabilities would also result in a clear hindrance in the 
development of software. For example, the full version of 
ChorusOS includes a ChorusOS Posix layer, which has 
communication functionalities. Anon-communicating simulation 

25 system cannot correctly host that ChorusOS Posix layer. More 
generally, in most cases, developers need a target simulation 
system enabling access to the external world, e.g. another 
host or target, connected e.g. through an Ethernet link. 

30 One of the purposes of this invention is to solve that 
problem. 

Generally, a pseudo network is used in the host to 
interconnect the simulation systems (virtual target machines) 
35 running on the host. This pseudo-network may also enable 
interconnection between the virtual target machines and the 
host system itself, thus enabling these virtual machines to 
access the external world, through any hardware connection 
available in the host. 
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Thus, the simulation systems run in a pseudo network, which 
will now be described by way of example as a pseudo Ethernet 
network. Generally, the host operating system has a 
corresponding pseudo-driver, which may communicate with an IP 
5 stack in the host operating system, and hence, with a real 
Ethernet driver. 

Figure 3 shows an example of such a software architecture, in 
host computer 1 of Figure 1, a Unix process PRl {e.g. PRIA, 
10 PRIB) lodges a ChorusOS simulator, which has: 

- one or more actors 110 ("actor" is the name of a process 
within ChorusOS ) ; 

- an IP stack 116, termed "Chorus TCP/IP stack", since it is 
part of the ChorusOS simulator; and 

15 - an Ethernet driver 118. 

Ethernet driver 118 has: 

- a common section 118C, defined in accordance with the rules 
of writing network drivers in the target operating system 

20 being simulated; and 

- a device dependent section 118P ("driver code"), which, in 
this invention, is in charge of interfacing with the pseudo- 
Ethernet network. 

25 More precisely, driver section 11 8P may invoke the pseudo- 
network manager included within the host operating system to 
transmit and receive Ethernet frames (in the example). Such 
invocations may be conveniently seen as WRITE and READ 
instructions . 

30 

In known fashion, the host operating system, e.g. SOLARIS 
(more precisely its kernel), has its own Solaris TCP/IP stack 
216, working with applications 210. It also has a SOLARIS 
Ethernet driver 218. Basically, driver 218 comprises: 
35 - a common section 218C, defined in accordance with the rules 
of writing network drivers in the host operating system; and 

- a (physical) device dependent section 218R, in charge of 
interfacing with the physical network 20 (e.g. Ethernet) via 
hardware interface 21; 
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In accordance with this invention, the host operating system 
is supplemented with : 

- a pseudo-network manager 214; and 

- a (pseudo) device dependent driver section 218P, which 
5 interfaces between host driver common section 218C and pseudo 

network manager 214. 

Functionally, driver section 218P may be viewed as a part of 
driver 218. However, it may be more conveniently implemented 
10 by a code module including both pseudo-network manager 214 
and driver section 21 BP (termed "pseudo-driver" or "further 
code", whether separate or gathered into a single module). 

Generally, the pseudo-network manager 214 may allow one or 
15 more of the following functions: 

i) each simulation process (e.g. FRIA) has its own Ethernet 
address, which is used by the pseudo-network manager 214 to 
interconnect the local simulators; 

ii) when communication with the host (and the external world) 
20 is implemented, the host also has its own Ethernet address on 

the pseudo-network; 

iii) the pseudo-network itself is an IP sub-network, which is 
assigned an IP "subnet" address (defining a range of IP 
addresses) ; 

25 iv) each simulation process (and the host, in case ii/), is 
also assigned an IP address included within the said range. 

In other words, the pseudo-network manager 214 may simulate 
a specific sub-network capable of interconnecting all the 
30 simulation processes running on the same host. 

Still in other words, elements 214, 218P, 218c, 216, 21BR, 
and 21 in host HI act as a gateway HIG between the pseudo- 
network PNl in HI and a physical network 20 (e.g. Ethernet or 
35 ATM) . The operation of the gateway will be described later on 
in more detail. 

Figure 4 shows a global network architecture, as may be 
obtained in accordance with this invention: 
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- a first station HI hosts simulation systems PRIA and PRIB; 

- a second station H2 hosts simulation systems PR2A and PR2B; 

- the pseudo-networks PNl and PN2 in stations HI and H2 are 
interconnected via medium 20 and gateways HIG and H2G, thus 

5 providing interconnection between all simulation systems 
PRIA, PRIB, PR2A and PR2B. 

Figure 5 shows the general structure of an Internet 
transmission system, using an IP stack. From bottom to top: 
10 - 20 is the network medium; 

- 21 is the network connection device, implementing the 
Medium Access Control functions (MAC); 

- 218 is the device driver; 

- 216 is the IP layer; 

15 - 215 is the transport layer; and 

- 211 is the application level. 

Transport layer 215 includes e.g. TCP and/or UDP functions, 
in charge of ensuring the desired communication, whatever the 

20 intermediate machines are, while regulating the flow of data. 
With TCP, the data should be transmitted with no error and 
should be received in the order they are transmitted. With 
UDP (User Datagram Protocol), the completion of the 
transmission is not guaranteed (the application layer should 

25 take care of checking it). 

Transport layer 215 may use e.g. TCP (Transmission Control 
Protocol), or UDP (User Datagram Protocol), depending upon 
whether receipt of a packet at the end side is, or is not, 

30 guaranteed by the protocol. In figure 5, application 211A 
uses TCP, while application 211B uses UDP. Application 211B 
must therefore make sure by itself that the UDP packets it 
sends have been correctly received. UDP may be used e.g. for 
access to remote files via the remote Network File System 

35 (NFS) calls. 

IP layer 216 manages the routing of IP packets through the 
different networks which the host is connected to. 
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Hardware device driver 330 matches the needs of device 21, 
e.g. an Ethernet driver in the example described. 

It will be appreciated that the word "driver", as used 
5 herein, does not necessarily refer to software code for 
direct interfacing to a hardware device. For example, the 
expression "pseudo-driver" is used mainly to reflect the fact 
that the pseudo driver simulates a hardware device for the 
Ethernet drivers 118, and also to reflect the fact that the 
10 pseudo-driver is an add-on requiring no fundamental 
modification of the host operating system. 

With operating systems like Solaris, this may be conveniently 
implemented using the known "stream" functionalities of 
15 Solaris. 

In this regard, the pseudo-network manager 214 may also be 
considered to be a driver. 

20 The flow chart of figure 6 shows the method of simulating the 
target environment with references to figure 3. According to 
a preferred embodiment of the invention, the target 
environment is represented by ChorusOS Simulator in the 
following method. Else, other sorts of Operating System 

25 simulators may also use this method according to the 
invention . 

Firstly, the host computer 1 of figure 1 enables to create a 
ChorusOS simulator encompassing pseudo-network layers, e.g. 

30 layers llOA, 116A and 118A in step 30. Other ChorusOS 
simulators may be also created. Then, in step 31, the host 
operating system loads a pseudo network manager 214. Thus, 
the necessary tools are provided to connect this host 
operating system and ChorusOS simulator(s) . In addition, 

35 these tools enable connexion between the ChorusOS simulators. 

To use these connexion tools, a Unix executable file loads 
the created ChorusOS simulator PRIA and its window interface 
on the display monitor. The other potential created ChorusOS 
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simulators may also be loaded. To link the ChorusOS 
simulator(s) with different networks (external network, 

pseudo Ethernet network) , a connexion is installed between 

ChorusOS simulator(s) network section 11 8A and the pseudo 
5 network manager 214 in step 33. 

Where different ChorusOS simulators exist, they may form a 
pseudo network of virtual machines via this pseudo-Ethernet 
network manager 214. In other words, the pseudo-Ethernet 
10 network manager 214 may be seen as a network data link, 
connecting all the available ChorusOS simulators. 

In step 34, ChorusOS simulator (s) may need to have a 
connexion with the external network. To this effect, if the 

15 pseudo Ethernet network exists, it may be interconnected with 
another pseudo Ethernet network of another host computer via 
a "real" network between the two host computers. Thus, a link 
is activated with the physical device via the host driver 
pseudo device section 218P and the host driver physical 

20 device section in step 35. 

When the pseudo network environment is constructed for 
ChorusOS simulator(8} , a launch may be done to use the 
simulated system and its network facilities in step 36. 

25 

The flow chart of Figure 7 shows the functions implemented in 
a host operating system stream driver according to the 
invention. The driver works here with e.g. two ChorusOS 
applications PRIA and PRIB, having respective IP stacks 116A 
30 and 116B (see Fig. 4). 

At step 810, driver 214 receives an Ethernet packet from IP 
stack 116A of application #1. It should be reminded here that 
the ChorusOS Ethernet driver 118A (Figure 3) of application 
35 PRIA has encapsulated the packet, as if it was to circulate 
on an Ethernet network medium. 
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At Step 812, driver 214 reads the Ethernet address in the 
packet. Reading the address in an encapsulated Ethernet 
packet is considered known to those skilled in the art. 

5 Step 814 determines whether the Ethernet address, as read, is 
the host's Ethernet address in the pseudo-network (Y), or the 
address of another local process connected to the pseudo- 
network, i.e. a "local address" (N). 

10 If the Ethernet address is a local one, at step 820, driver 
214 takes the packet, as it stands, and directs it to the IP 
stack 116B of e.g. local application #2. The IP stack will 
de-encapsulate the packet, and further process the packet in 
known fashion. 

15 

If the Ethernet address is the host's address, this means 
that the packet has to be sent to the host, so that e.g. a 
networking facility of the host operating system may be used. 
To this effect: 

20 - at step 818, the packet is received by driver section 218P, 
which passes it to driver 218C, which firstly removes the 
pseudo-network Ethernet header from the packet; 

- at step 830, driver 218C sends the de-encapsulated packet 
to IP stack 216 of the host computer; 

25 - at step 832, IP stack 216 processes the packet as usual, 
for having it to travel through the physical network 20 
connected to the host. 

The packet may thus reach another host. This will now be 
30 described as the receipt of a packet in the same host. 

Upon the usual receipt of a packet from the physical network, 
steps 842, 840 and 848 are performed. Steps 842, 840 and 848 
may be considered as substantially reciprocal to steps 832, 
35 830 and 818, respectively, i.e.: 

- at step 842, IP stack 216 receives the packet as usual; 

- at step 840, IP stack 216 sends the packet to driver 218; 

- at step 848, driver section 21BC re-encapsulates the packet 
with a pseudo-network Ethernet header; 
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Then, driver 214 sends the packet through the pseudo-network, 
to be delivered to a local application {step 820). 

The operation of the system will now be described, 
5 considering: 

- an application TAIA running in a ChorusOS simulator SMIA, 
i.e. a process PRIA of the host machine HMl ; and 

- an application TAIB running in a ChorusOS simulator SMIB, 
i.e. a process PRIB of the same machine HMl (the case of a 

10 different machine will be seen hereinafter) . 

Referring back to figure 3, when application TAIA running as 
actor 11 OA in PRIA sends a TCP packet PAl to an application 
TAIB running as actor llOB in PRIB, an exemplary detailed 
15 operation is as follows: 

- actor llOA executes the code of the TCP/IP stack 116A with 
packet PAl (actually a data flow), resulting in packet PAl 
crossing the TCP layer, and, then the IP layer, of stack 
116A; packet PAl now has a TCP/IP header; 

20 - then, packet PAl gets to the ChorusOS Ethernet driver 118A, 

- section 118CA of driver USA encapsulates packet PAl with 
an Ethernet header, including the Ethernet address of the 
destination simulation system PRIB; 

- section 11 SPA transmits the resulting Ethernet frame to 
25 pseudo network manager 214; 

- pseudo network manager 214 in turn transmits the Ethernet 
frame towards section IIBPB of driver 118B in the other 
simulator PRIB, 

- section 118PB delivers the frame to section 118CB which de- 
30 encapsulates packet PAl from its Ethernet header, and 

provides it to the IP/TCP stack 116B; 

- finally, actor llOB, in which application TAIB is running, 
recovers the data of packet PAl from TCP stack 116B. 

35 The above example uses a TCP packet. A UDP packet will be 
processed similarly, except that application TAIB may have to 
acknowledge receipt of the packet (or make any other action 
indicating that the packet has been received) . 
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Basically, the pseudo network manager of this invention 
allows communication between two simulators running on the 
same Solaris host, building e.g. a pseudo Ethernet network 
between them. 

5 

By adding driver section 218P, the host IP stack 216 is 
connected to pseudo network PNl. This enables communication 
between a simulation system and the host itself (applications 
in the host), and in addition, to communicate with the 
10 external world. 

In other words, a host running one or more simulation systems 
may be connected to at least two networks, as described with 
reference to figure 4 : 
15 - the pseudo Ethernet network which interconnects simulation 
systems ; and 

- any network, e.g. Ethernet or ATM, which the host is 
connected to. 

20 IP addresses may be used as follows: in TCP/IP stack 216, the 
destination IP address of an IP packet is used by the IP 
layer, in accordance with the Internet specifications, to 
determine whether the packet will be routed through the 
pseudo-network, or through the external network (or one of 

25 them) . 

The invention has been described with reference to the 
simulation of target systems within one or more host 
machines, and to establishing a hardware-like interconnection 

30 between such targets. It may apply to interconnection between 
simulated targets and real targets as well. It may also apply 
to simulating other hardware than communication devices for 
such target machines. In case several hosts are used, they 
may have different host Operating Systems, adapted to execute 

35 several tasks. Also, the same concept may be used for 
enabling communication between targets simulating different 
Operating Systems. 
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This invention also covers the proposed software code itself, 
especially when made available on any appropriate computer- 
readable medium. The expression "computer-readable medium" 
includes a storage medium such as magnetic or optic, as well 
as a transmission medium such as a digital or analog signal. 
The software code basically includes the so-called driver 
code and further code as described. 
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Claims 

1. A computer system comprising: 

- a host processing unit (1) capable of executing a host 
5 operating system (3), 

- driver code (118) capable of simulating a hardware device 
interface for a process running in said host operating system 
(3), and 

- further code (214) capable of processing data to and from 
10 the driver code (118) in accordance with the hardware device 

interface being simulated. 

2. The computer of claim 1, further comprising simulation 
code (SMI), capable of creating a process (PRl) running in 

15 said host operating system, while at least partially 
simulating another operating system within the process being 
created, 

said driver code (118P) being operable to provide the 
simulated operating system with a simulated hardware device 
20 interface. 

3. The computer system of claim 1, having a hardware device 
(21), and a device manager (216) in the host operating 
system, wherein said further code (214,218P) is capable of 

25 exchanging data between the driver code (118) and the device 
manager (216). 

4. The computer system of claim 1, wherein said further code 
(214) is capable of exchanging data between a first driver 

30 code (118A) for a first process (PRIA) running in said host 
operating system and a second driver code (118B) for a second 
process (PRIB) running in said host operating system. 



35 



5. The computer of claim 1, wherein said driver code (118) is 
capable of at least partially simulating a conimunication 
interface. 
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6. The computer of claim 1, wherein said driver code (118) is 
capable of at least partially simulating the interconnection 
of an IP stack (116) to a network (PN). 

5 7. The computer of claim 6, wherein said driver code (118) is 
capable of at least partially simulating the interconnection 
of an IP stack (116) to an Ethernet network (PN) . 

8. The computer of claim 3, wherein said device manager (216) 
10 of the operating system comprises an IP stack (216). 

9. The computer of claim 6, wherein said a host processing 
unit (1) further comprises at least one interface (218R,21) 
to another network (20), and said device manager (216) is 

15 capable of exchanging data between said network (PN) and said 
another network (20). 

10. The computer system of claim 9, wherein said further code 
(214,218P) is capable of exchanging data between a first 

20 driver code (118A) for a first process (PRIA) running in said 
host operating system and another host processing unit (H2) 
through said another network. 

11. A method of implementing software, comprising the steps 
25 of: 

a) running a process in a host processing unit (1) having a 
host operating system (3), 

b) simulating (118) a hardware device interface for said 
process, and 

30 c) providing said host operating system with further code 
(214) capable of exchanging data with said process in 
accordance with the hardware device interface being 
simulated. 

35 12. The method of claim 11, wherein said process of step a) 
is capable of at least partially simulating another operating 
system, and step b) provides the simulated operating system 
with a simulated hardware device interface. 
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13. The method of claim 11, wherein said further code of step 
c) is capable of exchanging data between the simulated 
hardware device interface and a physical hardware device 
interface. 

5 

14. The method of claim 11, wherein said further code (214) 
of step c) is capable of exchanging data between a first 
process (PRIA) and a second process (PRIB) running in said 
host operating system. 

10 

15. The method of claim 11, wherein step b) comprises at 
least partially simulating a communication interface. 

16. The method of claim 11, wherein step b) comprises at 
15 least partially simulating the interconnection of an IP stack 

(116) to a network (PN) . 

17. The method of claim 16, wherein step b) comprises at 
least partially simulating the interconnection of an IP stack 

20 (116) to an Ethernet network (PN). 

18. The method of claim 13, wherein said further code of step 
c) comprises exchanging data with a host IP stack (216). 

25 19. The method of claim 16, wherein step c) further comprises 
exchanging data between said network (PN) and another network 
(20). 

20. The method of claim 19, wherein step c) comprises 
30 exchanging data between said network (PN) and a remote 

station through said another network. 

21. A method of simulating a computer architecture having a 
device communication interface, comprising the steps of: 

35 a) in a host operating system (3), simulating another 
operating system, 

c) simulating a hardware device interface for said another 
operating system, and 
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d) supplementing said host operating system with further code 
(214) capable of processing data to and from said hardware 
device interface being simulated. 

5 22. The method of claim 21, wherein said further code (214) 
is arranged for exchanging data between first and second 
simulated hardware interfaces. 

23. The method of claim 22, wherein said first and second 
10 simulated hardware interfaces are in different computers 

interconnected via a network. 

24. The method of claim pi, wherein said first and second 
simulated hardware interfaces are in the same computer and 

15 interconnected via a pseudo-network. 

25. A computer program product comprising a computer-readable 
medium, having driver code (118) capable of simulating a 
hardware device interface for a process running in an host 

20 computer system. 

26. The computer program product of claim 25, comprising 
further code (214) capable of processing data to and from the 
driver code in accordance with the hardware device interface 

25 being simulated. 
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